home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1994 February: Tool Chest / Dev.CD Feb 94.toast / Tool Chest / Development Platforms / AppsToGo / AppsToGo.src / DTS.Lib / ! Functional Changes next >
Encoding:
Text File  |  1993-06-18  |  2.1 KB  |  46 lines  |  [TEXT/MPS ]
  1. GetNextWindow (and therefore GetNextDocument) have been modified to return
  2. invisible windows (or documents with invisible windows).  This change was made
  3. to allow kHideOnClose windows to not have to be saved in a global.  You can
  4. access the window or document by calling one of the above functions now, even
  5. if the window is curently hidden.
  6.  
  7. __________
  8.  
  9. The document procs for reading and writing the default document header are no
  10. longer initialized in File2.c.  They are left nil.  This means that you will no
  11. longer get reading and writing the default document header information as a
  12. default behavior.
  13.  
  14.  
  15. HOWEVER:
  16.  
  17. If you call DefaultInitDocument, they are set as they were before.  This means that
  18. if you still want this behavior and you use the hierarchical document package, then
  19. you will still get the benefit of reading and writing the default document header.
  20.  
  21. If you want to use the default document header facilities without the hierarchical
  22. document package, simply initialize the procs for reading and writing the header
  23. yourself in your own document initialization code.  You would add the following
  24. two lines (assuming that the document variable is called frHndl):
  25.  
  26.     (*frHndl)->fileState.readDocumentHeaderProc  = DefaultReadDocumentHeader;
  27.     (*frHndl)->fileState.writeDocumentHeaderProc = DefaultWriteDocumentHeader;
  28.  
  29.  
  30. This will give you the behavior you want.
  31.  
  32. The reason for the change is that some documents want the standard header and some don't.
  33. By explicitly setting them within the framework meant that the code got linked in, even
  34. if you then later set the procs to nil (because you didn't want the header).  This caused
  35. dead code to get linked in.  By assuming that the header isn't going to be used, and by
  36. having the application stating that they will indeed be used, we can prevent this dead
  37. code from getting linked in.
  38.  
  39. Again, if you call DefaultInitDocument, you do indeed get the header information.  This is
  40. done because it isn't a bad assumption to make.  If you are calling DefaultInitDocument,
  41. you want things handled for you, and this would include the header information.  If you are
  42. doing something custom, then you want more control.
  43.  
  44. __________
  45.  
  46.